前言：

Redis之所以速度这么快，是因为Redis是基于内存的数据库，进行读写操作时，redis都会现在内存中完成，然后定时的刷新到磁盘中去，RDB和AOF就是两种持久化内存中数据的方式。笼统来讲，RDB可以将某一时刻的所有数据写入硬盘中，相当于复制了一份数据；而AOF会在redis执行写命令时，将被执行的写命令复制到磁盘中，恢复数据的时候，redis会在原有基础上依次执行AOF文件中的写命令，从而恢复数据。下面会详细的讲下RDB和AOF的原理和机制。

一.RDB

Redis将某一时刻的快照（备份的数据库数据）保存成一种称为RDB格式的文件中，这种格式是经过压缩的二进制文件。redis保存和恢复文件，如图1和图2所示。

image.png

保存RDB数据的命令有两种，一个是save，一个是bgsave，一般用的都是bgsave命令。

save命令
save命令会阻塞redis服务器的进程，直到RDB文件创建完，在该期间，redis不能处理任何的命令请求，这就是save命令最大的缺陷。
bgsave命令
与save命令不同的是，bgsave在生成RDB文件时，会派生出一个子进程，子进程负责创建RDB文件，在此期间，主进程和子进程是同时存在的，因此不会阻塞redis服务器进程。
（可用lastsave命令查看生成RDB文件是否成功）

- 自动保存RDB文件

除了特殊情况外，我们一般是不会直接使用命令来生成RDB文件的，redis提供了自动生成RDB文件的功能。redis提供了使用配置文件配置的方式每隔一段时间自动执行一次bgsave命令，配置在redis.conf中，例如下面三条命令，只要满足了一个，bgsave就会被执行：

save 900 1
save 300 10
save 60 10000

含义：
Redis 服务器在 900 秒之内，对数据库进行了至少一次修改
Redis 服务器在 300 秒之内，对数据库进行了至少 10 次修改
Redis 服务器在 60 秒之内，对数据库进行了至少 10000 次修改

另外，设计RDB文件的配置选项还有：

dbfilename dump.rdb
dir ./
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes

含义：
dbfilename：配置 RDB 文件名称，一般叫dump.rdb
dir：配置 RDB 文件存放的路径
stop-writes-on-bgsave-error：当生成 RDB 文件出错时是否继续处理 Redis 写命令，默认为不处理
rdbcompression：是否对 RDB 文件进行压缩
rdbchecksum：是否对 RDB 文件进行校验和校验

- RDB快照持久化数据的优缺点：

优点：
1.采用子线程创建RDB文件，不会对redis服务器性能造成大的影响；
2.快照生成的RDB文件是一种压缩的二进制文件，可以方便的在网络中传输和保存。通过RDB文件，可以方便的将redis数据恢复到某一历史时刻，可以提高数据安全性，避免宕机等意外对数据的影响。

缺点：
1.在redis文件在时间点A生成，之后产生了新数据，还未到达另一次生成RDB文件的条件，redis服务器崩溃了，那么在时间点A之后的数据会丢失掉，数据一致性不是完美的好，如果可以接受这部分丢失的数据，可以用生成RDB的方式；
2.快照持久化方法通过调用fork()方法创建子线程。当redis内存的数据量比较大时，创建子线程和生成RDB文件会占用大量的系统资源和处理时间，对 redis处理正常的客户端请求造成较大影响。

二.AOF

AOF是redis对将所有的写命令保存到一个aof文件中，根据这些写命令，实现数据的持久化和数据恢复。

image.png

- AOF配置：

配置在redis.conf文件中，通过将appendonly:yes打开创建AOF文件功能。

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

含义：
appendonly：是否打开 AOF 持久化功能
appendfilename：AOF 文件名称
appendfsync：同步频率
对于同步频率有三种方式

always：redis执行每个写命令时，都同步写入硬盘，这样会严重降低redis性能；
everysec：每秒执行一次，显示的在这一秒内执行的写命令同步到硬盘；
no：不同步到硬盘（让操作系统来决定何时进行同步）。

- AOF文件生成机制：

生成过程包括三个步骤：命令追加、文件写入、文件同步。
redis打开AOF持久化功能之后，redis在执行完一个写命令后，把执行的命令首先追加到redis内部的aof_buf缓冲区膜末尾，此时缓冲区的记录还没有写到appendonly.aof文件中。然后，缓冲区的写命令会被写入到 AOF 文件，这一过程是文件写入过程。对于操作系统来说，调用write函数并不会立刻将数据写入到硬盘，为了将数据真正写入硬盘，还需要调用fsync函数，调用fsync函数即是文件同步的过程，只有经过了文件的同步过程，写命令才真正的被保存到了AOF文件中。appendfsync 就是配置同步的频率的选项。

- AOF重写：

redis不断的将写命令保存到AOF文件中，导致AOF文件越来越大，当AOF文件体积过大时，数据恢复的时间也是非常长的，因此，redis提供了重写或者说压缩AOF文件的功能。比如对key1初始值是0，调用incr命,100次，key1的值变为100，那么其实直接一句set key1 100 就可以顶之前的100局调用，AOF重写功能就是干这个事情的。
重写时，可以调用BGREWRITEAOF命令重写AOF文件，与新建子线程bgsave命令的工作原理相似。也可以通过配置文件配置什么条件下对AOF文件重写。

auto-aof-rewrite-percentage 100 #当前AOF文件大小和上一次重写时AOF文件大小的比值
auto-aof-rewrite-min-size 64mb  #文件的最小体积

重写步骤:
1.创建子进程进行AOF重写
2.将客户端的写命令追加到AOF重写缓冲区
3.子进程完成AOF重写工作后，会向父进程发送一个信号
4.父进程接收到信号后，将AOF重写缓冲区的所有内容写入到新AOF文件中
5.对新的AOF文件进行改名，原子的覆盖现有的AOF文件

- AOF优缺点：

优点：
1.提供了多种同步命令的方式，默认1秒同步一次写命令，最多丢失1秒内的数据；
2.如果AOF文件有错误，比如在写AOF文件时redis崩溃了，redis提供了多种恢复AOF文件的方式，例如使用redis-check-aof工具修正AOF文件（一般都是最后一条写命令有问题，可以手动取出最后一条写命令）；
3.AOF文件可读性交强，也可手动操作写命令。
缺点：
1.AOF文件比RDB文件较大；
2.redis负载较高时，RDB文件比AOF文件具有更好的性能；
3.RDB使用快照的方式持久化整个redis数据，而aof只是追加写命令，因此从理论上来说，RDB比AOF方式更加健壮，另外，官方文档也指出，在某些情况下，AOF的确也存在一些bug，比如使用阻塞命令时，这些bug的场景RDB是不存在的。

三.参考资料

RDB：https://leehao.me/Redis-%E5%BF%AB%E7%85%A7%E6%8C%81%E4%B9%85%E5%8C%96%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0/
AOF:https://blog.csdn.net/lihao21/article/details/75269622
两种方式比较（细节比较全）：https://my.oschina.net/davehe/blog/174662

redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

Redis持久化：RDB（快照）和AOF（写命令）